基于 Prometheus 进行容器监控的5个常见难点解读

当我们使用Kubernetes进行容器化管理时，传统监控工具无法对Kubernetes做到统一有效的全面监控，全面监控Kubernetes也就成为我们需要探索的问题。以下是几个容器环境下基于Prometheus 进行监控的难点解读，由社区同行分享，供大家参考。

1、在Kubernetes集群内实现部署Prometheus的方案是什么，这种方案有什么优势？

@晓风 光大科技 研发工程师：

1、我们的方案是使用Prometheus Operator以及helm工具在Kubernetes集群上部署Prometheus服务，Prometheus Operator允许用户能够使用简单的声明性配置来配置和管理Prometheus实例，这些配置将响应、创建、配置和管理Prometheus监控实例。

使用Operator部署了Prometheus之后就可以不用再管Prometheus Server了，以后如果要添加监控对象或者添加告警规则，只需要编写对应的ServiceMonitor和Prometheus资源就可以，不用再重启Prometheus服务，Operator会动态的观察配置的改动，并将其生成为对应的Prometheus配置文件其中Operator可以部署、管理Prometheus Service。

2、方案优势，在Prometheus Operator中，它会创建Prometheus、ServiceMonitor、AlertManager以及PrometheusRule 4个CRD资源对象。这些API对象全都是用CRD定义好Schema的，api-server会帮我们做校验，这就大大降低了配置异常的风险。ServiceMonitor和PrometheusRule这两个对象解决了Prometheus配置难维护的问题。

其次，Prometheus Operator借助Kubernetes把Prometheus服务平台化了，实现Prometheus as a Service。在有了Prometheus和Alertmanager这样非常明确的API对象之后，用户就能够以Kubernetes 平台为底座，自助式地创建Prometheus服务或Alertmanager 服务。这些新的API对象基于Operator模式，具有基于Kubernetes进行扩展的优势。

@mtming333  甜橙金融翼支付 系统运维工程师：

容器平台Prometheus分指标联邦架构方案：

1、单个生产机房按采集指标划分K8S调度部署多个prome 1、prome 2

2、用K8S保证基层prome的可用性

3、汇聚数据至上层联邦prome A与prome B，两个联邦节点独立写库，两套持久数据库单点部署，分别保留独立数据，以保证数据多副本

4、告警数据从2个联邦层prome获取，经过gossip筛选产生告警

5、Kibana经过负载均衡获取联邦prome数据出图

2、容器环境监控中如何预估每天Prometheus数据库存储量的增长？

@晓风 光大科技 研发工程师：

在一般情况下，Prometheus中存储的每一个样本大概占用1-2字节大小。预估Prometheus Server的本地磁盘空间大小，使用以下公式计算：

磁盘大小 = 保留时间 * 每秒获取样本数 * 样本大小

（每秒获取样本数可由抓取间隔内采集的样本总数除以抓取间隔获取）

@mtming333 甜橙金融翼支付 系统运维工程师：,

社区文档，借花献佛：

3、目前Prometheus能否支持对网络设备的监控，如何支持采用snmp ssh 等协议方式的监控？

@晓风 光大科技 研发工程师： 

Prometheus有snmp的exporter可以实现网络监控。Prometheus通过snmp_exporter抓取网络设备流量数据。 

用Prometheus监控网络设备流量首先需要确定安装prometheus 的机器已经被网络设备允许获取它的数据。

4、Prometheus监控k8s如何自动发现服务？

@晓风  光大科技 研发工程师：

在Kubernetes下Prometheus需要与Kubernetes的API进行交互，从而能够动态的发现Kubernetes中部署的所有可监控的目标资源。 

目前主要支持5种服务发现模式，分别是：Node、Service、Pod、Endpoints、Ingress。 

为了让Prometheus能够获取到当前集群中所有节点的信息， 我们在Prometheus配置文件中 ，添加如下Job配置：

- job_name: 'kubernetes-nodes'
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  # 这里需要指定用于访问Kubernetes API的ca以及token文件路径 
  kubernetes_sd_configs:
  - role: node
  # 通过指定kubernetes_sd_config的模式为node，Prometheus会自动从Kubernetes中发现到所有的node节点并作为当前Job监控的Target实例，发现的节点/metrics接口是默认的kubelet的HTTP接口

对于Ingress，Service，Endpoints, Pod的使用方式也是类似的，这里给出了一个完整Prometheus配置的示例：

apiVersion: v1
data:
  prometheus.yml: |-
    global:
      scrape_interval:     15s 
      evaluation_interval: 15s
    scrape_configs:
    
    - job_name: 'kubernetes-nodes'
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: node
      
    - job_name: 'kubernetes-service'
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: service
      
    - job_name: 'kubernetes-endpoints'
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: endpoints
      
    - job_name: 'kubernetes-ingress'
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: ingress
      
    - job_name: 'kubernetes-pods'
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: pod
      
kind: ConfigMap
metadata:
  name: prometheus-config

更新配置文件， 并重建Prometheus实例：

$ kubectl apply -f prometheus-config.yml
configmap "prometheus-config" configured

$ kubectl get pods
prometheus-69f9ddb588-rbrs2        1/1       Running   0          4m

$ kubectl delete pods prometheus-69f9ddb588-rbrs2
pod "prometheus-69f9ddb588-rbrs2" deleted

$ kubectl get pods
prometheus-69f9ddb588-rbrs2        0/1       Terminating   0          4m
prometheus-69f9ddb588-wtlsn        1/1       Running       0          14s

Prometheus使用新的配置文件重建之后，打开Prometheus UI，通过Service Discovery页面可以查看到当前Prometheus通过Kubernetes发现的所有资源对象。

同时Prometheus会自动将该资源的所有信息，并通过标签的形式体现在Target对象上。

@mtming333 甜橙金融翼支付 系统运维工程师： 

拉取全量标签，按需过滤、替换、丢弃后再利用

5、Pod内存使用率一直升高，请问有什么办法可以优化内存占用吗？

Pod内存使用率一直升高，我们怎样知道大概多久之后会到达Limit值，并在一定时刻触发告警，在Pod被杀掉之前进行排查？如果数据指标数量大导致Promethues占用内存很高，出现Prometheus容器OOM，请问有什么办法可以优化内存占用吗？

@晓风 光大科技 研发工程师：

1、Promtheus提供了基础的预测能力，基于当前的变化速度，推测一段时间后的值。Prometheus的Deriv和Predict_Linear函数可以满足这种需求。

predict_linear函数：对曲线变化速率进行计算，起到一定的预测作用。比如当前这1个小时的内存可用率急剧下降，这种情况可能导致内存已满，这时可以使用该函数，用当前1小时的数据去预测未来几个小时的状态，实现提前告警。

以mem_free为例，mem_free仅为举例，实际内存可用以mem_available为准。

执行查询：mem_free{instanceIP="xxx.xxxx.xxx.xxx"}/1024/1024

结果显示最近一小时的free值一直在下降。

deriv函数可以显示指标在一段时间的变化速度:

deriv(mem_free{instanceIP="xxx.xxxx.xxx.xxx"}[1h])

predict_linear函数是预测基于这种速度，最后可以达到的值:

predict_linear(mem_free{instanceIP="xxx.xxxx.xxx.xxx"}[1h], 2*3600)/1024/1024

你可以基于设置合理的告警规则，如小于10时触发告警:

rule: predict_linear(mem_free{instanceIP="xxx.xxxx.xxx.xxx"}[1h], 2*3600)/1024/1024 <10

predict_linear与deriv的关系: 含义上约等于如下表达式，不过predict_linear稍微准确一些。

 deriv(mem_free{instanceIP="xxx.xxxx.xxx.xxx"}[1h]) * 2 * 3600
+
  mem_free{instanceIP="xxx.xxxx.xxx.xxx"}[1h]

2、如果采集任务的数据指标数量非常巨大，就要考虑Prometheus的hash分区采集，分摊压力。还可以考虑省去一些在生产过程中没必要的指标。

@mtming333 甜橙金融翼支付 系统运维工程师：

这个要结合JMX exporter Prometheus让架构师看看

更多交流内容可点击阅读原文

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到

 资料/文章推荐：

欢迎关注社区 "监控"技术主题 ，将会不断更新优质资料、文章。地址：

https://www.talkwithtrend.com/Topic/3937

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场